前言

在 Kubernetes (K8s) 中，Service 可以讓 Pod 之間互相溝通，但當流量要進入整個 Cluster 時，我們需要更高階的控制。Ingress 便是專門用來管理 外部流量進入 K8s 內部服務的「入口控制器」。
本文會從實務例子開始，逐步解釋 Ingress 的用途、配置方式，以及它有哪些限制。

為什麼需要 Ingress？

情境案例：

• 你有三個微服務：frontend、backend、api。
• 如果不用 Ingress，你可能需要為每個 Service 建立一個 LoadBalancer 或 NodePort。這樣會有：
  • 成本高：每個 Service 都要申請一個 Public IP。
  • 管理複雜：Domain name 要一個一個綁定。

Ingress 則是透過一個控制器 (Ingress Controller，如 NGINX、Traefik、HAProxy) 來統一管理外部流量。
只要設定規則，就能把同一個 Domain 的不同 Path/Host 分流到不同 Service。

Ingress 的基本結構

一個簡單的 Ingress Manifest：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
spec:
  rules:
  - host: myapp.com
    http:
      paths:
      - path: /frontend
        pathType: Prefix
        backend:
          service:
            name: frontend-svc
            port:
              number: 80
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-svc
            port:
              number: 80

這樣設定後：

• myapp.com/frontend → 轉發到 frontend-svc
• myapp.com/api → 轉發到 api-svc

Ingress 的優點

1. 統一入口：只需要一個 LoadBalancer 就能管理多個 Service。
2. 整合 TLS/HTTPS：可在 Ingress 層做 SSL/TLS 終止。
3. 反向代理功能：依據 Host/Path 規則分流。

Ingress 的短處

雖然 Ingress 很方便，但隨著服務變多，問題也逐漸浮現：

1. 規格太簡單

   • Ingress CRD 定義的功能過於基本：Host/Path 分流。
   • 想要做流量治理 (Rate Limiting、Header Routing、重試策略) 就要靠不同的 Controller 擴展，沒有標準化。

2. 強烈依賴 Controller 實作

   • 不同 Controller（NGINX, Traefik, Istio）支援的 annotation 完全不同。
   • 從一個 Controller 換到另一個 Controller，YAML 幾乎要重寫。

3. 缺乏進階流量治理

   • 比如 Canary Release、Traffic Splitting、藍綠部署，Ingress 規範本身不支援。

4. 缺乏一致性 API

   • 每個團隊都要重新學習自己 Controller 的寫法，不利於跨專案或多雲環境。

總結

Ingress 幫 Kubernetes 解決了「如何讓外部流量進來」的基本問題，但它的設計過於簡單，導致不同實作之間差異巨大，缺乏一致性。
下一篇，我會介紹 Gateway API，它是 CNCF 社群提出來的新一代標準，目標就是補足 Ingress 的不足。